home *** CD-ROM | disk | FTP | other *** search
- Path: news.lpr.carel.fi!usenet
- From: Ari Lukumies <aril@cmt.lpr.mail.carel.fi>
- Newsgroups: comp.lang.c++
- Subject: Re: char vs. unsigned char ???
- Date: Tue, 23 Jan 1996 16:26:48 +0200
- Organization: Carelcomp Forest
- Message-ID: <3104F028.5100@cmt.lpr.mail.carel.fi>
- References: <DLGEKq.1zq@avalon.chinalake.navy.mil>
- NNTP-Posting-Host: renoir.cclahti.carel.fi
- Mime-Version: 1.0
- Content-Type: text/plain; charset=us-ascii
- Content-Transfer-Encoding: 7bit
- X-Mailer: Mozilla 2.0b6a (WinNT; I)
-
- sean harvey wrote:
- >
- > I recently encorporated some functions from another program compiled and
- > linked under an older version (Microsoft C version 6.0) into my program
- > (MSVC 7.0).
- > [rest snipped]
-
- As I first got hold of MSC v7 (Win32 version), I ran into strange problems. After some
- debugging, I found out that there was a bug in MSCv7 (probably there's no more, but I
- think I'll say this anyway...). It seemed that a code where you shift a 8-bit value by
- 8 bits, for instance:
-
- unsigned int x = 0;
- unsigned char c = 'A';
-
- x = ((unsigned int)c) << 8;
-
- compiled to:
-
- MOV AX,0 /* This is placement for x */
- MOV AL,'A' /* x = c */
- MOV AH,AL /* Compiler optimized: x = c << 8! */
- /* Here, they forgot to zero the lower part (AL) of AX! */
-
- The solution to this was to not use literal shift counts (8 here), but to place them
- into a variable:
-
- int cnt = 8;
-
- ...
- x = ((unsigned int)c) << cnt;
-
- This would yield the correct result. So, if your code contains shifts like that, I'd
- check them out by the debugger (what kind of code the compiler emitted).
-
- Later,
- AriL
-
- --
- All my opinions are mine and mine alone.
-